Should we try to integrate Java or ctags into the AppImage?

In my view, the AppImage should be as standalone as possible to avoid future incompatibility and usage issues.
If some tools cannot be integrated into it, let's discuss why not?

appimagetool is needed for AppImage building. Currently, the documentation (doc/packaging.md) suggests to download it from a GitHub release (https://github.com/AppImage/AppImageKit/releases/13). However, this is only a 2MB file. On one hand, it would make things easier if we include this binary file in the CodeCompass repository. On the other, it's not a good practice to store binary files in a VCS.

I would say that for building it the AppImage, it is fine to have an initial step: downloading the required tool for it. Also, we will do it in the CI mostly, and not manually building it.

@mcserep

In my view, the AppImage should be as standalone as possible to avoid future incompatibility and usage issues.

Yes, this is an important aspect for AppImages and I agree with it.
Currently, this packaging works by trying to locate shared objects on the packager's system rather than compiling everything from source. This way we can create a distribution independent packaging workflow, meaning make appimage should work on any system once CodeCompass was successfully built.

To address the missing binaries:

• ctags: we can locate it using a bash script and add it to the package
• Java: downloading a JDK binary release
• g++: this is technically not needed, however the C++ parser looks for headers under /usr/include/ and /usr/include/c++/.
• Databases: I believe this part should be installed separately. AppImages work by creating a temporary directory and extracing the AppImage contents. If we want to add databases to the AppImage, we need a way to store the database state persistently elsewhere.

Let me know if this is a workable path or we should try something else moving forward.

Hi @wbqpk3,
Thanks for the update!

Yes, this is an important aspect for AppImages and I agree with it. Currently, this packaging works by trying to locate shared objects on the packager's system rather than compiling everything from source. This way we can create a distribution independent packaging workflow, meaning make appimage should work on any system once CodeCompass was successfully built.

I miss a point here. Isn't the whole goal of creating an AppImage is to run CodeCompass without building it? What is the benefit of having an AppImage, if it is "trying to locate shared objects on the packager's system"? Wouldn't that mean that the created AppImage is not transferrable between machines?

@mcserep

What is the benefit of having an AppImage, if it is "trying to locate shared objects on the packager's system"?

I think there is a misunderstanding.
We can assume that the packager have already built CodeCompass successfully, meaning the required dependencies (ODB, Boost, LLVM11, Thrift, etc.) are already installed on their system. Therefore, during the AppImage creation, we can just locate these shared objects on the packager's system and then simply add them to the AppImage.

I looked at the tarball creation script (https://github.com/Ericsson/CodeCompass/blob/master/.gitlab/build-deps.sh), and it builds every dependency (ODB, LLVM, Boost, Python, etc.) from source.
The workflow I outlined above would locate these dependencies rather than build them when creating an AppImage.

My current implementation locates the required shared objects fine using CMake. A bit problematic ones which I listed above: ctags, Java, etc. since these are not shared objects.

@mcserep

What is the benefit of having an AppImage, if it is "trying to locate shared objects on the packager's system"?

I think there is a misunderstanding. We can assume that the packager have already built CodeCompass successfully, meaning the required dependencies (ODB, Boost, LLVM11, Thrift, etc.) are already installed on their system. Therefore, during the AppImage creation, we can just locate these shared objects on the packager's system and then simply add them to the AppImage.

I looked at the tarball creation script (https://github.com/Ericsson/CodeCompass/blob/master/.gitlab/build-deps.sh), and it builds every dependency (ODB, LLVM, Boost, Python, etc.) from source. The workflow I outlined above would locate these dependencies rather than build them when creating an AppImage.

My current implementation locates the required shared objects fine using CMake. A bit problematic ones which I listed above: ctags, Java, etc. since these are not shared objects.

@wbqpk3 That sounds okay, but did you try to copy the built AppImage to another computer (preferably with a minimal preinstalled software), and to run it there?

E.g. Boost seems to missing from the image:

./CodeCompass-x86_64.AppImage parser -h
/tmp/.mount_CodeCo80c486/usr/bin/CodeCompass_parser: error while loading shared libraries: libboost_log.so.1.74.0: cannot open shared object file: No such file or directory